Universal Serial Bus (USB) is a communications architecture that gives a personal computer the ability to interconnect with a variety of devices using a simple four-wire cable. USB protocols can configure devices at startup or when they are plugged in at run time. These devices are broken into various device classes. Each device class defines the common behavior and protocols for devices that server similar functions.
The invention described below is used in conjunction with the Human Interface Device (HID) class. The HID class consists primarily of devices (referred to herein as HID devices or as HID class devices) that are used by humans to control the operation of computer systems. Typical examples of HID class devices include:
Keyboards and pointing devices--for example, standard mouse devices, trackballs, and joysticks. PA1 Front-panel controls--for example: knobs, switches, buttons, and sliders. PA1 Controls that might be found on devices such as telephones, VCR remote controls, games or simulation devices--for example: data gloves, throttles, steering wheels, and rudder pedals. PA1 Devices that may not require human interaction but provide data in a similar format to HID class devices--for example, bar-code readers, thermometers, or voltmeters.
The current HID specification, which is hereby incorporated by reference, is promulgated by a non-profit organization referred to as the USB--IF and is available from that organization which is located in Hillsboro, Oreg. The specification can also be accessed through the Internet at www.usb.org. The HID specification is likely to evolve, although its most significant characteristics are fairly well defined and accepted at this time.
One well-defined and accepted characteristic of HID devices, with which this invention is primarily concerned, is that such devices transmit and receive data in data packages called "reports." Devices are given a great deal of flexibility in formatting such reports.
Reports contain two different types of data generated by HID devices: buttons and values--generically referred to herein as data items. Each data item is generated by a control, such as a key, a slider, a single axis of a joystick, etc. A button-type data item is binary, having one of two values: 0 or 1. Button-type data items are generated by such things as keys or switches. A value-type data item has a range of values, usually indicating an analog position of a continuously-variable control such as a slider, joystick axis, or throttle. Although HID devices usually generate input data items, reports can also be received by HID devices, enabling a computer to control LED, speaker volumes, and other output devices on an HID device.
Each control has an associated "usage," specified by the HID device manufacturer. Usages supply computer application programs with information about parameters being measured by different controls and what should be done with the data items generated by the controls--for example, X, Y, and Z input. The HID specification itself includes usage definitions for a number of different devices, such as keyboards, joysticks, sliders, and other devices.
An HID usage contains two components: a usage page and a usage index. The usage page corresponds to a particular device. Probably the most common usage pages are the "generic desktop" page and the "keyboard" page. Usage indexes correspond to specific controls within the page, such as joystick keys, axes, sliders, keyboard keys, etc.
In practice, the term "usage" sometimes refers to a usage index. In the main body of this document (excluding the section, "Windows NT HID Client Design Guide"), however, "usage" refers to a pair of values comprising a usage page and a usage index. The term "usage specification" is used herein to refer more generally to either one or both components of a usage.
As already mentioned, the arrangement and formatting of HID reports varies tremendously from device to device. Generally, each report contains a plurality of data items occurring in an arbitrary order specified by the device, wherein each data item has an arbitrary number of bits and an arbitrary bit alignment within a report. Furthermore, data items themselves can be reported in different formats, such as bit field formats and index array formats.
A device can also separate its data items into two or more reports, in which case each report begins with a report ID. The reports themselves are of various, non-uniform lengths, and are generated by the HID device only when a data item contained in the report changes.
In addition, a device can group various controls into different "collections," wherein each collection has its own specified usage. Collections can span different reports. Collections can also be nested within each other. Data items corresponding to the same usage can be reported in different collections.
Each HID device generates an HID report descriptor that specifies the reports generated by the device. For each report, the report descriptor describes the arrangement and formatting of the data items contained in the report, as well as the usages associated with each data item.
HID report descriptors are coded using a sophisticated protocol. Any application program that uses HID report data must first parse the associated report descriptor to determine how to interpret individual reports, and how to find data items within reports. Parsing a report descriptor is an extremely complex task.
The HID protocol described above is very efficient in terms of bandwidth. In addition, it is fairly simple to implement in HID devices. However, the scheme presents a number of difficulties for application program developers. These difficulties relate primarily to the flexibility allowed in HID reports and to the complexity of the HID report descriptors.
Writing an application program for a single, known HID device is not difficult. In this case, the developer knows, ahead of time, the exact nature of all available data items and how they are arranged and formatted within HID reports.
Difficulties arise, however, when attempting to write a program for use with different peripherals, all of which potentially implement their reports in different and unforeseeable ways. One peripheral might utilize only a single report, while another might divide its data items into two or three reports. One keyboard might report keystrokes as bit fields, while another might utilize an index array. One joystick might have only very basic controls, while another might provide more sophisticated controls like a hatswitch and airplane yoke controls. Even the sizes of reports are different from peripheral to peripheral, making it difficult to determine required buffer sizes. Collections, similarly, can be implemented quite differently in different peripherals.
Although all of this information is available from the report descriptor, parsing the information is quite difficult-buffering and parsing the actual reports is similarly quite complicated when such a variety of formats must be accommodated.
Thus, although HID technology has the potential of making a variety of devices or peripherals compatible with a given application program, such compatibility can presently be realized only with very significant investment in the development of the application program, so that the application program can adapt to the various report formats available to HID peripherals.